A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Closed the issue.

I think it's very likely that people are relying on this at this point.

Well, the number of 3rd party codecs should be pretty low, and this change is a backward incompatible change on purpose: it fixes an old bug.

But it is not the documented behavior (or this should be re-documented for UnicodeError explicitly, or maybe it is documented elsewhere and I didn't find it (I am no more on my dev session)). Users should rely on the non-args value and instead access the named properties I think.

Users should rely on the non-args value and instead access the named properties I think.

I agree with that. But it doesn't prevent to fix exc.args member, an old Python bug.

args is not documented explicitly in UnicodeError: https://docs.python.org/dev/library/exceptions.html#UnicodeError

It's documented on the BaseException: https://docs.python.org/dev/library/exceptions.html#BaseException.args

Yes, but the fact that it says:

The tuple of arguments given to the exception constructor

makes me feel that we should not break this part of the contract. That is, args should contain the original arguments tuple, and it doesn't matter how we change the attributes.

OTOH, we could have maybe have an astuple() method that would return the args as one could expect. It'd be a new method though but changing the meaning of args is risky. Now, after re-reading the issue, I also spotted in the PEP the following:

Should further encoding errors occur, the encoder is allowed to reuse the exception object for the next call to the callback.

So, re-using the same exception object should be allowed. Thus, I wouldn't consider the current behavior an "old" bug.

Note that a similar argument could be said for OSError. We can change the errno but args is not updated. Also OSError.args only contains the two first arguments for backward compatibility (it's documented as such). I would rather recall the fact that re-using UnicodeError exceptions does not update args.